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CROSS REFERENCE TO RELATED APPLICATIONS 

This application is a continuation of U.S. patent 
5 application Ser. No. 10/115,268 filed April 2, 2002, from 

which priority is claimed under all applicable sections of 
Title 35 of the United States Code including, but not limited 
to, Section 120. 

TECHNICAL FIELD 

10 The present invention pertains to how the respective data 

stores on different devices, holding data items of one or more 
applications such as desktop calendars and e-mail, are 
synchronized. More particularly, the present invention 
concerns how the data structure of such data stores is 

15 synchronized. 

BACKGROUND ART 

Today it is possible for a businessperson to use an e- 
mail application and a calendar application (for keeping track 
of appointments) on a mobile phone or a palm (handheld) 

20 computer (or some other mobile terminal) and have an assistant 

use the same applications on a desktop computer to keep track 
of e-mail sent and received by the assistant on behalf of the 
businessperson, and to keep track of appointments for the 
businessperson. In such an arrangement, it is often the case 

25 that the data items (also called here data units) for the e- 

mail application and data items for the calendar are kept in a 
data store on the mobile phone and in another data store on 
the desktop. Thus, when changes are made to either of the 
data stores, each including data items for both the e-mail and 

30 the calendar application, the data stores need to be 

synchronized. In synchronizing respective data stores (i.e. 
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synchronizing both the data items and data structure of the 
two data stores) used by two applications running on different 
equipment the contents of the two data stores are set to 
correspond to each other based on a protocol in which changes 
5 since a last synchronization are communicated, conflicts 

between changes made on both pieces of equipment are resolved 
(according to some policy) , and changes are made to either the 
data items or their organization or both in one or both of the 
data stores. 

10 A facility is being developed for synchronizing such data 

stores based on what is called SyncML (synchronization markup 
language) , being developed under the so-called SyncML 
Initiative. (See http://www.syncml.org/ for information about 
SyncML, including standards and specifications for SyncML, and 

15 the SyncML Initiative, especially including the SyncML 

Representation Protocol and the SyncML Sync Protocol . ) SyncML 
is an open industry standard for a common language for 
universal synchronization of remote data (i.e. data items 
stored in different equipment and so in different data stores) 

2 0 and personal information across multiple networks, platforms 

and devices. With SyncML, data items, but not yet data 
structure, can be synchronized on different devices connected 
via one or more interconnecting networks, including, for 
example, a Universal Mobile Telecommunications System (UMTS) 

2 5 Radio Access Network (UTRAN) and the Internet, where the 

communication may be wireless in whole or in part or may be 
wireline. Thus, the devices may communicate via, for example, 
fixed networks (including wireless networks) , infrared, cable, 
or Bluetooth. 

3 0 Besides being used to synchronize data stores, SyncML 

(i.e. the language) can be used for device management, and 
more particularly for transferring management actions between 
a client and a management server for the client. See 
http://www.syncml.org/ to find the specification, SyncML 
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Device Management Protocol . SyncML Device Management Protocol 
allows management commands to be executed on management 
objects and it uses a package format similar to the SyncML 
Synchronization Protocol and the SyncML Representation 
5 Protocol. A management object might reflect a set of 

configuration parameters for a device. Actions that can be 
taken against this object might include reading and setting 
parameter keys and values. Another management object might be 
the run- time environment for software applications on a 

10 device. Actions that can be taken against this type of object 

might include installing, upgrading, or uninstalling software 
elements. Actions are represented by SyncML Device Management 
Protocol Commands, which are described in SyncML 
Representation Protocol, Device Management Usage. The 

15 commands and message structure used correspond identically to 

that of the SyncML Synchronization Protocol. (Thus, the so- 
called document type definition for the Management Protocol is 
the document type definition from SyncML Synchronization 
Protocol . ) 

20 Until now, the progress of mobile data synchronization 

has mostly been determined by restrictions. Data store 
synchronization has been based on a set of different, 
proprietary protocols, each functioning only with a very 
limited number of devices, systems and data types. These non- 
25 interoperable technologies have complicated the tasks of 
users, manufacturers, service providers, and developers. 
Further, a proliferation of different, proprietary data store 
synchronization protocols has placed barriers to the extended 
use of mobile devices, has restricted data access and delivery 
3 0 and limited the mobility of the users. 

As the popularity of mobile computing and communications 
devices grows, users want access to updated information and 
applications wherever they are, and using whatever device is 



-3- 



available, prompting a need for an open standard such as the 
SyncML standard. 

SyncML uses the syntax of the so-called Extensible Markup 
Language (XML) as set out in Extensible Markup Language (XML) 
5 1.0, a product of the World Wide Web Consortium (W3C) XML 

Activity, having a website at: http://www.w3.org. For 
information about XML, see: http://www.w3.org/XML. 

As used here, the terminology data item or data unit 
indicates a unit of data that is organized into what are here 
10 called folders that in turn make up what is here called a 

directory structure, also called here a data structure. 
Referring to Fig. 4, a directory structure is shown including 
various folders, each of which can include one or more data 
units . 

15 The term directory structure or data structure and the 

term folder are to be understood broadly. First, a folder 
should be understood to be any container of data units. Thus, 
for example, what is called a folder in various operating 
systems (such as Windows, available from Microsoft 

20 Corporation) is to be understood by the term folder as used 

here, but so is a record in a table of a relational database, 
since a record in such a table includes fields, which are data 
units. Even such a field can be considered a folder, since a 
field contains characters, numbers, or other elements that can 

25 be considered data units, and thus each field is a folder. 

The term directory structure or data structure indicates 
the arrangement of folders in the data store, such as for 
example a tree structure of folders in a directory maintained 
by an operating system, in which case the data units would be 
30 files. But the term directory structure or data structure 

should be understood to also encompass directory structures 
maintained internally by applications, i.e. not maintained by 
an operating system, but instead maintained by an application 



running under an operating system. An example is the 
directory structure maintained by most e-mail applications, 
which usually always include at least two folders: a received 
e-mail (in-box) folder and a transmitted e-mail (sent) folder. 
Moreover, the terminology directory structure or data 
structure should also be understood to encompass internal 
directory structures that are shared by different applications 
(so that the directory structure is not internal to only one 
application, but to several, usually well - interfaced 
applications, any of which can make changes to it) . Further, 
the terminology directory structure or data structure should 
also be understood to encompass both system directory 
structures and internal directory structures. In the case of 
an internal directory maintained by an e-mail application, a 
data unit would be an e-mail, a kind of internal file. In a 
directory structure of either type, a folder can include, in 
general, data units that belong to different applications, and 
an application knows whether a data unit belongs to it or to 
another application based either on some attribute maintained 
in association with the data unit or based on the application 
keeping a private table of all data units that belong to it, 
wherever they may be located. Also, since as has already been 
explained, a folder can indicate for example a record in a 
table of a database or even a field within such a record, the 
terminology directory structure or data structure should also 
be understood to encompass even a database structure (when a 
folder is a record) or a record structure (when a folder is a 
field) . It is important to understand that the term folder is 
thus used expansively, to indicate any container of data 
units, and the terminology directory structure or data 
structure has a correspondingly expansive meaning. 

A user of an application can make changes to both the 
data units that belong to the application (such as adding a 
new data unit or replacing a data unit with an updated version 



because the user has used the application to change the 
contents of the data unit, and so on) as well as to how the 
data items are stored (such as adding a new folder and moving 
some data units from an already existing folder to the new 
folder), i.e. to both the data units as well as to the folders 
(i.e. the overall directory structure). According to the 
prior art for SyncML, however, if a user changes folders on a 
device, SyncML cannot be used to synchronize the data store on 
the device with a corresponding data store being maintained on 
another device; the prior art for SyncML allows only 
synchronizing with respect to changes in data units. 

A SyncML message is a nested structure, and one or more 
SyncML messages can be associated with what is called a SyncML 
package. The SyncML Message is an individual XML document 
consisting of one or more elements each of one or more element 
types. The document consists of a header, specified by the 
SyncHdr element type, and a body, specified by the SyncBody 
element type. The SyncML header specifies routing and 
versioning information about the SyncML Message. The SyncML 
body is a container for one or more SyncML Commands. The 
SyncML Commands are specified by individual element types. 
The SyncML Commands act as containers for other element types 
that describe the specifics of the SyncML command, including 
any data or met a- information . 

SyncML defines request commands and response commands. 
Request commands include, for example: add (a command that 
allows the originator to ask that one or more data units be 
added to data accessible to the recipient) ; alert (allowing 
the originator to notify the recipient of a condition; copy 
(allowing the originator to ask that one or more data units 
accessible to the recipient be copied) ; delete (allowing the 
originator to ask that one or more data units accessible to 
the recipient be deleted or archived) ; get (allowing the 
originator to ask for one or more data units from the 



recipient) ; and search (allowing the originator to ask that 
the supplied query be executed against one or more data units 
accessible to the recipient) . The only response commands are 
currently: status (indicating the completion status of an 
5 operation or that an error occurred while processing a 

previous request) ; and results (used to return the data 
results of either a Get or Search SyncML Command) . 

SyncML uses identifiers to identify data units or 
folders. The identifiers are included in what are called the 

10 Source and Target element types, and can be a combination of 

Uniform Resource Identifiers (URIs) , Uniform Resource Names 
(URNs) , and textual names. (To indicate an International 
Mobile Equipment Identifier (IMEI) , SyncML uses an IMEI URN 
type. The IMEI URN specifies a valid, 15 digit IMEI. In 

15 addition, SyncML uses the SyncML URN type to identify SyncML 

specific name spaces and unique names. Other URN types may 
also be used in the LocURI element type.) 

As already mentioned, the SyncML representation protocol 
(i.e. a SyncML message) is a document mark-up consisting of 

20 XML element types. The element types are defined in terms of 

their purpose or usage, parent elements, any restrictions on 
content or use and content model . The element types include 
so-called common use elements, message container elements, 
data description elements, protocol management elements, and 

25 . protocol command elements. 

Common use element types are element types used by other 
SyncML element types, and include, for example, archive, for 
indicating that the data specified in a delete command should 
be archived by the recipient of the delete command, rather 
3 0 than simply deleted. Thus the delete command can use the 

archive common use element and so is referred to as the parent 
element of the archive common use element type, in this 
context. Another common use element type is the Cmd element 
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type, which is used to specify the SyncML command referenced 
by a Status element type (and so the Status element type is 
the parent element in this context) . Another is the CmdID 
element type, which is used to specify a SyncML message-unique 
5 command identifier, and can have various parent elements, 

including: Add, Alert, Atomic, Copy, Delete, Exec, Get, Map, 
Put, Replace, Results, Search, Sequence, Status, and Sync. 

Of particular note in respect to the invention are the 
common element types LocName, LocURI , Source, and Target. 

10 LocName is used to specify the display name for the target or 

source address, and so can have as parent elements Target or 
Source. LocURI specifies the target or source specific 
address, and can also have as parent elements Target or 
Source. The common element type Source is used to specify 

15 source routing or mapping information; its parent elements 

include: Item, Map, Mapltem, Search, Sync, and SyncHdr. 
Target is used to specify target routing or mapping 
information, and its Parent Elements include: Item, Map, 
Mapltem, Search, Sync, and SyncHd . 

20 Message container element types provide basic container 

support for SyncML messages. Three such element types are: 
SyncML, for specifying the container for a SyncML message, and 
having no parents since it is what is called a root or 
document element; SyncHdr, for specifying the container for 

25 the revisioning information or the routing information (or 

both) in the SyncML message, and having as a parent element a 
SyncML element; and SyncBody, for specifying the container for 
the body or contents of a SyncML message, and also having as a 
parent element a SyncML element. 

30 Data description elements are used as container elements 

for data exchanged in a SyncML Message; data description 
elements include the following element types: Data, for 
specifying discrete SyncML data, and used by (parent elements) 
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Alert, Cred, Item, Status, and Search element types; Item, for 
specifying a container for item data, and used by (parent 
elements) Add, Alert, Copy, Delete, Exec, Get, Put, Replace, 
Results, and Status; and Meta, for specifying meta- information 
5 about the parent element type, and used by (parent elements) 

Add, Atomic, Chal, Copy, Cred, Delete, Get, Item, Map, Put, 
Replace, Results, Search, Sequence, and Sync. 

The protocol management elements include, at present, 
only the element type Status, for specifying the request 
10 status code for an indicated SyncML command, and used by 

(parent element) SyncBody. 

Finally, there are the Protocol Command Elements. These 
include the command elements already mentioned, i.e. for 
example: Add, for specifying that data be added to a data 
15 collection, used by (parent elements) Atomic, Sequence, Sync, 

SyncBody; Delete; Replace; and so on. 

All of the above element types are set out in the 
standard, SyncML Representation Protocol, available on the 
Internet at : 

2 0 http : //www. syncml . org/ docs/ syncml_represent_vl 1_2 002 0215 .pdf . 

Communicating changes in a directory structure is not 
problematic if the same application takes care of handling the 
data and handling the communication according to a 
synchronization protocol. But in case of the more general 

25 problem, in which on each device several applications share a 

data store organized as a directory structure, storing their 
respective data units in one or more of the folders of the 
directory structure, how best to arrange for synchronizing not 
only data units but also folders, i.e. how to structure a 

30 synchronization protocol for doing so, is not clear. 

According to the open standard, SyncML Synchronization 
Protocol, a product of the SyncML Initiative, each of two 
remote devices having respective data stores to be 
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synchronized (in any respect) , includes a synchronization 
(sync) agent (one per device, and so serving possibly many 
different applications) and one or more application entities, 
and following synchronization protocol (i.e. communicating 
5 according to the synchronization protocol set out in the 

standard) is the responsibility not of the applications, but 
of the sync agents. (Only the sync agent understands SyncML, 
not the applications.) But only the applications know whether 
a data unit has been changed since the most recent, already - 

10 performed synchronization. There are some options for how to 

extend the SyncML synchronization protocol that require 
including in each of the applications a knowledge of SyncML, 
like what is encoded in the sync agent, and some options that 
require the sync agent to be able to interpret data units the 

15 way the different applications do. 

What is needed is a way for SyncML (or any analogous 
synchronization language) to refer to aspects of data 
organization, such as folders in a directory structure, in a 
way that minimizes the demands on the sync agent and 
20 application, and so avoids having to replicate code or folder 

information . 

DISCLOSURE OF THE INVENTION 

Accordingly, in a first aspect of the invention, a method 
is provided for at least partially synchronizing a first data 

25 store residing on a first device and a second data store 

residing on a second device, the data stores each being used 
for storing data as data units in folders, the folders in 
combination defining a data structure, the method comprising: 
the first device sending a message to the second device; 

30 wherein information about data in the first data store is 

transmitted in said message, and information about a change in 
the data structure of the first device is also transmitted in 
the message in an element or field of the message; and further 
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wherein said information about data in the first data store is 
placed in the message in an element or field different from 
the element or field where the information about a change in 
the data structure is placed. 

5 In accord with the first aspect of the invention, the 

element or field where the information about data in the first 
data store is placed or the element or field where the 
information about a change in the data structure is placed may 
be a field of the message. 

10 Also in accord with the first aspect of the invention, 

the information about data in the first data store may be 
included in a data element of the message, which may be a data 
element of a protocol command element . 

Also in accord with the first aspect of the invention, 
15 the information about a change in the data structure may be 

included in a non-data element of the message, which may be a 
non-data element of a protocol command element. 

Also in accord with the first aspect of the invention, 
the information about a change in the data structure may 
20 include folder information. 

Also in accord with the first aspect of the invention, a 
data identification element may be contained in a protocol 
command element in the message, and the protocol command 
element in combination with the data identification element 
25 may indicate the information about a change in the data 

structure of the first data store. 

Also in accord with the first aspect of the invention, a 
data identification element may be included in the message and 
the information about a change in the data structure of the 
30 first data store may be provided in the data identification 

element . 
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Also in accord with the first aspect of the invention, 
the first device may function as a client in a client - server 
protocol and the second device as a server in the client - 
server protocol . 

Also in accord with the first aspect of the invention, 
the first device may function as a server in a client -server 
protocol and the second device as a client in the client - 
server protocol, and the step of the first device sending the 
message may be responsive to a client message from the second 
device and may include resolving any conflicts posed by the 
client message in respect to the first data store. 

Also in accord with the first aspect of the invention, 
the data in the data stores may be used for device management 
by applications hosted on the devices. 

Also in accord with the first aspect of the invention, 
the data in the data stores may be used as user data by 
applications hosted on the devices . 

In a second aspect of the invention, a computer program 
product is provided comprising: a computer readable storage 
structure embodying computer program code thereon for 
execution by a computer processor, with said computer program 
code characterized in that it includes instructions for 
performing the steps of a method according to the first aspect 
of the invention. 

In a third aspect of the invention, a device is provided 
adapted for at least partially synchronizing a first data 
store residing on the device with a second data store residing 
on a second device, the data stores each being used for 
storing data as data units in folders, the folders having 
interrelationships and so defining a data structure, the 
device comprising: means for sending to the second device a 
message; wherein information about data in the first data 
store is transmitted in said message, and information about a 
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change in the data structure of the first device is also 
transmitted in t*he message in an element or field of the 
message; and' further wherein said information about data in 
the first data store is placed in the message in an element or 
5 field different from the element or field where the 

information about a change in. the data structure is placed. 

In accord with the third aspect of the invention, the 
device may be either a wireless communication terminal or a 
wireline communication terminal, and may serve as . 

10 Also in accord with the third aspect of the invention, 

the device may function as a client in a client -server model. 

Also in accord with the third aspect of the invention, 
the device may function as a server in a client - server model, 
and may further comprise means for receiving a request to 
15 synchronize from the second device, and for then sending the 

message in response to the request to synchronize. 

Also in accord with the third aspect of the invention, ( 
the device may further comprise means for receiving the 
message, and may function as a server in a client-server model 
20 and include means for resolving conflicts posed by the 

message . 

Also in accord with the third aspect of the invention, 
the data in the data stores may be used for device management 
by applications hosted on the devices, or may be used as user 
25 data by applications hosted on the devices. 

In a fourth aspect of the invention, a system is 
provided, comprising a first device according to the third 
aspect of the invention, and also comprising the second device 
hosting the second data store. 

3 0 In accord with the fourth aspect of the invention, the 

first device may function as a server in a client-server model 
and the second device as a client in the client-server model. 



-13- 



Further, the means for sending to the second device a message 
may be responsive to a request sent by the second device to 
synchronize to the second device. 

Thus, the invention provides a way to synchronize data 
stores for changes in folders, data stores that can be used by 
applications in connection either with user data or with 
device management; now both changes in folders and changes in 
data units in one data store can be reflected in another data 
store . 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other objects, features and advantages of 
the invention will become apparent from a consideration of the 
subsequent detailed description presented in connection with 
accompanying drawings, in which: 

Fig. 1 is a block diagram/ flow diagram of a client (such 
as a mobile phone) and a server (such as a network server or 
PC) exchanging SyncML messages to synchronize their 
respective data stores, according to the invention; 

Fig. 2 is a schematic of a SyncML message according to 
the invention; 

Fig. 3 is a flowchart illustrating one arrangement for 
cooperation between the components of a client and server 
during synchronization using messages constructed according 
to the invention; and 

Fig. 4 is a schematic of a directory structure (according 
to the prior art) . 

BEST MODE FOR CARRYING OUT THE INVENTION 

Referring now to Fig. 1, a client 11 is shown 
synchronizing a client data store 11c with a corresponding 
server data store 12c of a server 12 . (The data stores can be 
of use in either device management or for holding user data, 
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such as for example e-mails.) A data store can in general 
include one (or even more) system directory structures and 
possibly also one or more internal directory structures (i.e. 
an internal directory structure being one maintained by one or 
5 more applications as opposed to an operating system) , with any 

directory structure able to be represented as illustrated in 
Fig. 4, so that a directory structure is a tree structure of 
folders, each folder able to include one or more data units 
(such as files, i.e. units of data maintained in a system 

10 directory structure, or units or data maintained by 

applications in an internal directory, such as e-mails 
maintained by an e-mail application) and one or more other 
folders of the tree structure. The synchronizing occurs via 
the exchange of SyncML messages, although messages according 

15 to any similarly structured or analogous language could also 

be used. Some of the SyncML messages being exchanged include 
commands for synchronizing the data stores 11c 12c with 
respect to data units, and some for synchronizing the data 
stores with respect to the data organization, i.e. so that 

2 0 both data stores have an equivalent structure in terms of 

folders, at least in so far as the applications are concerned 
on whose behalf the synchronization is being performed. The 
client 11 is any device that plays the role of a client in a 
client/ server model, and according to SyncML protocol, a 

25 client (usually a laptop or a portable phone or other wireless 

terminal) sends all changes in its data store 11c to the 
server 12, a device (usually for example a desktop computer) 
having the role of a server in the client/ server model. (Of 
two devices synchronizing their respective data stores, the 

30 device having the greater computing capability will usually 

assume the role of the server.) 

The client 11 and the server 12 include one or more 
respective application entities 11a 12a, and they also include 
a (generic, i.e. not particularized to a particular 
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application) respective sync agents lib 12b. The server 
application entity 12a differs from the client application 
entity 11a in that it not only interfaces with the server sync 
agent, but also interfaces with a server sync engine 12f, 
which has no counterpart in the client 11. Similarly, the 
server sync agent 12c differs from the client sync agent 11c 
in that it also interfaces with the server sync engine 12f. 
The client/ server application entity lla/l2a is for example a 
calendar application used to keep track of appointments for a 
salesperson. If an appointment is made on the client device 
11, then the appointment information is stored in the client 
data store 11c as a new file. Later, either at the request of 
the client 11 or the prompting of the server 12, the data 
store 12c is synchronized with the client data store 11c in 
respect to the new data (i.e. the new file) . In addition, if 
a change is made to the directory structure on the client data 
store 11c, then again, the client data store 11c and server 
data store 12c must be synchronized, in this case with respect 
to the directory structure, i.e. in respect to what folders 
are used to hold the data units for the application . Also, 
any change made on the server data store 12c, including 
changes to either folders or data units for the applications 
11a 12a, will require synchronizing the client data store 11c 
and the server data store 12c by the exchange of SyncML 
messages . 

Still referring to Fig. 1, the SyncML messages may be 
communicated according to various transport connections 14, 
including for example hypertext transport protocol (HTTP) , 
wireline session protocol (WSP) , and object exchange protocol 
OBEX) . (The transport connections may be provided using any 
kind of physical layer connection, including either a wireless 
connection or a wireline connection.) As shown, when the 
server 12 communicates a SyncML message to the client 11 (and 
vice versa) , the server sync agent 12b uses a sync interface 



(I/F) 12d to provide the message to a server sync adapter 12e 
which in turn provide the SyncML message to the client 11 via 
the transport connection 14 . At the receiving end, a client 
sync adapter lie receives the SyncML message and passes it to 
a client sync I/F lid which in turn provides it to the client 
sync agent lib. 

Now, to provide for synchronizing the data stores 11c 12c 
with respect to changes in folders as well as data units (so 
that the same data units are in the same or equivalent folders 
on each device, and the content of each corresponding data 
unit is the same) , the invention has SyncML use the same 
commands for changing folders as are used to change data 
units; thus, changes to folders are made by issuing messages 
conveying operational elements (Protocol Command Elements) , 
such as Sync, Add, Replace and Delete, in which the affected 
folders are referenced within what are here called Data 
Identification Elements, meaning either TARGET or SOURCE 
elements, external to DATA elements. To make a change to a 
data unit, SyncML according to the prior art calls for a 
message referencing the data unit within a DATA element nested 
in an operational element. It is the use of a reference to 
affected folders external to the DATA element (i.e. a data 
description element) that gives the invention advantages over 
other possible arrangements for referring to affected folders 
(namely, not having to duplicate code enabling SyncML parsing 
by each application, and not having to include in each sync 
agent code for interpreting the data units of each different 
application) . 

Referring now to Fig. 2, thus, according to the 
invention, folders (and thus the data organization in terms of 
directories) affected in the course of synchronizing the data 
stores 11c 12c are identified or indicated in the LocURI 
elements 2 6a 2 7a of the Source element 2 6 and the Target 
element 2 7 of a protocol command element 2 5 (such as replace) 



external to (i.e. not contained in) a data element 28 2 9 (i.e. 
a particular type of data description element) . Both the 
Target and Source elements are here called Data Identification 
Elements , to stand in contradistinction to the data elements 
5 28 29 that contain the data units. The data identification 

elements according to the invention are typically embedded in 
a non-data element container (such as an item element) which 
in turn is embedded in a protocol command element 24. The 
protocol command element 24 is conveyed as part of the 
10 SyncBody container element 23, along with a SyncHdr container 

element 22, both included in a SyncML container element, i.e. 
a SyncML message 21. 

When changes have been made to both data units and 
folders, the folders must be synchronized first, and messages 
15 are formulated so that first the folder changes are made and 

then the data unit changes. Each change (to either data units 
or folders) is accomplished via an operational element. The 
changes to the folders should be arranged to come before any 
changes to the data units. 

2 0 Thus, according to the invention, when sending a folder 

change in a message, e.g. when adding a new folder to a 
client, the data element (i.e. a particular type of data 
description element) of the operational element "add" is left 
empty or no such ("add") element is indicated in the message, 
25 and the folder information (folder's ID and the full path) is 

conveyed within the LocURI element of a data identification 
element (a Source element or a Target element) external to any 
data element. 

The following SyncML message fragment shows how, within a 
30 replace command, to address a folder having the identifier 7 

and located within a folder having the identifier 1. 
<Replace> 

<Item> 

3 5 <Source> 
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<LocURI> . /1/7/</LocURI> 
<LocName>My own messages </LocName> 
</Source> 



</Replace> 

When addressing a data unit in a folder (as opposed to 
the folder itself), the folder's identifier and the path of 
the folder with respect to the root of the directory structure 
(in case of a tree structure) is transferred within the LocURI 
of the Target and Source common element types of an 
operational element, i.e. a protocol command element (such as 
Replace or Delete) . The example below shows how to address an 
item having a locally unique identifier (LUID) of 123 in a 
folder having the identifier 7, when the folder 7 is located 
within a folder having the identifier 1. 
<Replace> 

<Item> 

<Source> 

<LocURI> . /1/7/123</LocURI> 

<LocName>Hi there ! </LocName> 
</ Source > 

</Replace> 

Below is an example of a SyncML message according to the 
invention including the operational elements (commands) used 
for creating folder information in the recipient end (which 
could be either the client or the server) . In the example, 
clear text XML used; in a wireless environment, clear text 
would normally not be used, and instead WBXML (wireless binary 
XML) would be used. 

< SyncML > 
<SyncHdr> 

<VerDTD>l . 0</VerDTD> 

<VerProto>SyncML/l . 0</VerProto> 

<SessionID>l</SessionID> 

<MsgID>2</MsgID> 

<Target ><LocURI>OBEX : //123 45 6 /messaging- server < /LocURI >< /Target > 
<SourcexLocURI>IMEI : 4 93 0 0510 05 92 8 0 0< /LocURI >< /Source > 

</SyncHdr> 

<SyncBody> 

<Sync> 

<CmdID>3</CmdID> 
<Target> 



<LocURI> . /Messaging/MMS</LocURI> 
</Target> 
<Source> 

<LocURI> . /MMS</LocURI> 
5 </Source> 
<Replace> 

<! --Sending the folder structure --> 

<CmdID>4</CmdID> 

<Item> 

10 <Source> 

<LocURI> . /100/</LocURI> 
<LocName>My Folder</LocName> 
</Source> 
</Item> 

15 </Replace> 
</SyncML> 

The above SyncML message fragment renames the folder having a 
LocURI of ./100/ so as to have a name of "My folder". 

2 0 Synchronization 

According to the invention, (two-way) synchronization can 
be done as described for example in the specification, SyncML 
Synchronization Protocol, version 1.1, augmented as follows. 

If there are modifications in the client's folder 
2 5 structure after the previous sync, then the following 

requirements for the operational elements (e.g., Replace, Add 
and Delete) within the Sync element should be met. 

Sending the folder information should be done before 
sending any message objects, i.e. the Replace commands 
30 should be specified in the modifications package before 

specifying the commands defining any modifications for the 
messaging ob j ects . 

Data element should not be specified for the Item 
element . 

35 If the operation is not a deletion, the Mark element 

within the Meta element of the Item element should be used 
to carry information about the folder (e.g. the type of the 
folder) . 
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If the operation is not a deletion, the LocName element 
within the Source of the Item element should specify the 
folder's displayable name. 

The LocURI element within the Source of the Item element 
5 should specify the folder identifier and the entire path of 

the folder, i.e. all possible subf older identifiers should 
also be specified in the LocURI element . The folder 
identifiers should be delimited by the slash character 

( V) . 

10 If there are modifications in messaging objects in the 

client after the previous sync, then the following 
requirements for the operational elements within the Sync 
element should be met . 

If the operation is not a deletion, the LocName element 
15 within the Source of the Item element should specify the 

displayable name of the message. 

If the operation is not a deletion, the Mark element 
within the Meta element of the Item element should be used 
to carry information about the state of the message (e.g. 
20 read/unread information) . 

The LocURI element within the Source of the Item element 
should specify the item's identifier including the entire 
path, i.e. all possible folder and subf older identifiers 
should also be specified in the LocURI element. The item 
25 identifier (i.e. the LUID) should always be presented as the 

last value in the LocURI element. The folder identifiers 
should be delimited by the slash character (V) - 

What follows is an example of a client sending 
modifications to a server. 

3 0 <SyncML> 

<SyncHdr> 

<VerDTD>l . 0</VerDTD> 

<VerProto>SyncML/l . 0</VerProto> 

<SessionID>l</SessionID> 
3 5 <MsgID>2</MsgID> 

<Target xLocURI >0BEX : // 1234 56 /messaging - server< /LocURI ></Target > 
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< Source ><LocURI>IME I : 4 93 0 05100592 800</LocURIx/Source> 
</SyncHdr> 
<SyncBody> 

<Status> 

5 <CmdID>l</CmdID> 

<MsgRef >l</MsgRef > 

< CmdRe f > 0 < / CmdRe f > 
<Cmd>SyncHdr</Cmd> 

<TargetRef >IMEI : 4 93005 100592 800</TargetRef > 

1 0 <SourceRef >0BEX : // 1234 56/messaging-server</SourceRef > 

<Data>212</Data> < ! - -Statuscode for OK, authenticated for session--> 
</Status> 
<Status> 

<CmdID>2</CmdID> 
15 <MsgRef >l</MsgRef > 

< CmdRe f > 5 < / CmdRef > 
<Cmd>Alert</Cmd> 
<TargetRef > . /MMS </ Target Re f > 
<SourceRef > . /Messaging/MMS</SourceRef > 

2 0 <Data>200</Data> <!- -Statuscode for Success--> 

<Item> 
<Data> 

<Anchor xmlns= ' syncml rmetinf ' ><Next>2 00005022T093223Z < /Next ></ Anchor > 
</Data> 
25 </ltem> 
</Status> 
<Sync> 

<CmdID>3</CmdID> 
<Target> 

3 0 <LocURI > . /Messaging/MMS< /LocURI > 

</Target> 
<Source> 

<LocURI > . /MMS</LocURI > 
</Source> 

3 5 <Meta> 

<Mem xmlns= ' syncml rmetinf ' > 
< FreeMem>8 1 0 0 < / FreeMem> 

< ! --Free memory (bytes) in MMS database on a device --> 
<FreeId>81</FreeId> 

4 0 <! --Number of free records in MMS database- -> 

</Mem> 
</Meta> 
<Replace> 

<! --Sending the folder structure --> 
4 5 <CmdID>4</CmdID> 

<Item> 

<Source> 

<LocURI> . /100/</LocURI> 
<LocName>My Folder</LocName> 
50 </Source> 

</Item> 
</Replace> 
<Replace> 

<! --Sending the folder structure --> 
55 <CmdID>5</CmdID> 

<Item> 

<Source> 

<LocURI >./102/</ LocURI > 
<LocName>My mes sages </LocName> 
6 0 </Source> 

</Item> 
</Replace> 
<Replace> 

<! --Sending the actual message --> 
6 5 <CmdID>6</CmdID> 

<Meta> 

<Type xmlns= ' syncml rmetinf ' >application/wap . mms - mes sage </ Type > 
</Meta> 
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<Item> 

<Source> 

<LOCURI>./100/123</LOCURI> 
<LocName>Hi there ! < / LocName > 
5 </Source> 

<Data><!--The MMS data would be placed here . - - ></Data> 
<Meta> 

<Mark xmlns= 1 syncml :metinf 1 >unread</Mark> 
<!-- Item's status is 'unread' --> 
10 </Meta> 

</Item> 
</Replace> 
</Sync> 
<Final/> 
15 </SyncBody> 
</SyncML> 

If there are modifications in the server's folder 
structure after the previous sync, then the following 

2 0 requirements for the operational elements within the Sync 

element should be met . 

Sending the folder information should be done before 
sending any message objects, e.g. the Replace command should 
be specified in the modifications package before specifying 
25 any commands defining the modifications for the messaging 

obj ects . 

Data element should not be specified for the Item 
element . 

If the operation is not a deletion, the Mark element 

3 0 within the Meta element of the Item element should be used 

to carry information about the folder (e.g. the type of the 
folder) . 

If the operation is not a deletion, the LocName element 
within the Target of the Item element should specify the 
35 folder's displayable name. 

If the operation is an addition, then the LocName of the 
Source element should specify the folder's displayable name. 

The LocURI element within the Target of the Item element 
should specify the client side folder identifier and the 
40 entire path of the folder, i.e. all possible subf older 

identifiers should also be specified in the LocURI element. 
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The folder identifiers should be delimited by the slash 
character ( V ) • 

If the operation is an addition, then the LocURI of the 
Source element should specify the server side folder 
5 identifier and the path. The LocURI of the Target element 

should specify the folder path of the client. The folder 
identifier should not be specified within the Target LocURI. 

If there are any modifications in messaging objects in the 
server after the previous sync, then the following 
10 requirements for the operational elements within the Sync 

element should be met . 

In case the operation is an addition, then the LocName 
element within the Source of the Item element should specify 
the displayable name of the message. The LocURI element 

15 within the Source of the Item element should specify the 

item's identifier including the entire path, i.e. all 
possible folder and subfolder identifiers should also be 
specified in the LocURI element. The item identifier (i.e. 
the GUID) should always be presented as the last value in 

20 the LocURI element. The folder identifiers should be 

delimited by the slash character (*/')- The LocURI of the 
Target element should specify the folder path of the client, 
but the item identifier should not be specified within the 
Target LocURI . 

25 If the operation is a modification, then the LocName 

element within the Target of the Item element should specify 
the displayable name of the message. The LocURI element 
within the Target of the Item element should specify the 
item's identifier including the entire path, i.e. all 

30 possible folder and subfolder identifiers should also be 

specified in the LocURI element. The item identifier (i.e. 
the LUID) should always be presented as the last value in 
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the LocURI element. The folder identifiers should be 
delimited by the slash character (V) . 



If the operation is a deletion, the LocURI element within 
the Source of the Item element should specify the client 
5 side item identifier including the entire path of the 

client, i.e. all possible folder and subf older identifiers 
should also be specified in the LocURI element. The folder 
identifiers should be delimited by the slash character 

( V) . 

10 If the operation is not a deletion, the Mark element 

within the Meta element of the Item element should be used 
to carry information about the state of the message (e.g. 
read/unread information) . 

What follows is an example of a server sending 
15 modifications to a client. 

<SyncML> 

<SyncHdr> 

<VerDTD>l . 0</VerDTD> 
<VerProto>SyncML/l . 0</VerProto> 
2 0 <SessionID>l</SessionID> 
<MsgID>2</MsgID> 

<Target><LocURI>IMEI :4 93 005100 5 9280 0</LocURIx/Target> 
<SourcexLocURI>OBEX : / /123456/messaging-server</LocURI></Source> 
</SyncHdr> 

2 5 <SyncBody> 

<Status> 

<CmdID>l</CmdID> 

<MsgRef >2</MsgRef xCmdRef >0</CmdRef ><Cmd>SyncHdr</Cmd> 
<TargetRef >OBEX : //12 3 4 56/messaging- server</TargetRef > 

3 0 <SourceRef >IMEI :4 93 00 510 0592 800</SourceRef > 

<Data>2 0 0</Data> 
</Status> 

<Status>< ! - -This is a status for the client modifications to the server. --> 
<CmdID>2</CmdID> 

3 5 <MsgRef >2</MsgRef xCmdRef >3</CmdRef ><Cmd>Sync</Cmd> 

<TargetRef > . /Messaging/MMS</TargetRef > 
<SourceRef > . /MMS</SourceRef > 

<Data>200</Data> < ! - -Statuscode for Success--> 
</Status> 
40 <Status> 

< Cmd I D> 3 < / Cmdl D > 

<MsgRef >2</MsgRef xCmdRef >4</CmdRef ><Cmd>Replace</Cmd> 
<SourceRef > . /!00/</SourceRef > 

<Data>200</Data> <!- -Statuscode for Success--> 
45 </Status> 
<Status> 

<CmdID>3</CmdID> 

<MsgRef >2</MsgRef xCmdRef >5</CmdRef ><Cmd>Replace</Cmd> 
<SourceRef > . /l02/</SourceRef > 
50 <Data>200</Data> < l - -Statuscode for Success--> 

</Status> 
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<Status> 

<CmdID>3</CmdID> 

<MsgRef >2</MsgRef xCmdRef >6</CmdRef ><Cmd>Replace</Cmd> 

<SourceRef > . /100/123</SourceRef > 
5 <Data>200</Data> < ! - -Statuscode for Success--> 

</Status> 
<Sync> 

<CmdID>4</CmdID> 

<TargetxLocURI> . /MMS</LocURI >< /Target > 

1 0 < Source ><LocURI> . /Messaging/MMS</LocURIx/Source> 

<Add> 

<! --Sending the folder structure --> 

<CmdID>5</CmdID> 

<Item> 

15 <Target> 

<LocURI > . /102/</LocURI> 
</Target> 
<Source> 

<LocURI> . /4044/223/</LocURI> 

2 0 <LocName>My Own messages</LocName> 

</Source> 
</l tem> 
</Add> 
<Replace> 

2 5 <CmdID>6</CmdID> 

<Meta> 

<Type xmlns= ' syncml :metinf ' >application/wap . mms - me s sage </ Type > 
</Meta> 
<Item> 

3 0 <Target> 

<LocURI> . /102/1023</LocURI> 
<LocName>A holiday picture » </LocName> 
< /Target > 

<Data><!--The MMS data would be placed here . - - ></Data> 
35 <Meta> 

<Mark xmlns= 1 syncml :metinf ' >send</Mark> 
</Meta> 
</Item> 
</Replace> 

4 0 <Add> 

<CmdID>7</CmdID> 
<Meta> 

<Type xmlns= 1 syncml imetinf ' >applicat ion/wap . mms-message</Type> 
</Meta> 

4 5 <Item> 

<Target> 

<LocURI>. /102/</LocURI> 
</Target> 
<Source> 

5 0 <LocURI>. /4 044/1980556</LocURI> 

<LocName>Hello John! </LocName> 
</Source> 

<Data><!--The MMS data would be placed here . - - ></Data> 
<Meta> 

55 <Mark xmlns= ' syncml : met inf 1 >read</Mark> 

</Meta> 
</Item> 
</Add> 
</Sync> 
60 <Final/> 
</SyncBody> 
</SyncML> 

In the command above having command identifier (ID) 5, 
65 the server uses a globally unique identifier (GUID) of 
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./4 044/223/ for a folder having the name "My Own Messages." 
As set out in the SyncML Sync Protocol (Standard) , version 
1.1, at section 5.3, the client sync agent will assign a LUID 
for the folder and will then return to the server a map 
showing how the LUID (of the client) is related to the GUID 

(of the server). (See the example given at section 5.3.1.) 

Some Folder manipulations 

As already explained, a folder is just another object in 
a synchronization session. Take as an example a case where a 
user has created a new folder in the client device (e.g. a 
laptop or a mobile phone) , so that the client must send a 
Replace command containing the information about the new 
folder in the next synchronization session. This would be 
done with the following SyncML message fragment, according to 
the invention. 

<Sync> 

<CmdID>4</CmdID> 

<TargetxLocURI > . /MMS</LocURI >< /Target > 
<Source><LocURI > . /Messaging/MMS</LocURI ></Source> 
<Replace> 

<CmdID>5</CmdID> 
<Item> 

<Source> 

<LocURI > . /4 /I/ </LocURI > 
<LocName>My messages</LocName> 
</Source> 
</Item> 
</Replace> 

</Sync> 

When the recipient receives an operation (i.e. Replace or Add) 
that does not contain the Data element, it should assume that 
the operation is a folder manipulation operation. 

Creating Folders 

Creating folders is done by specifying a Replace or an Add 
command. The following is an example of how to create a new 
folder, having the folder identifier 7, in the Inbox folder of 
the client (with the client side Inbox folder having an 
identifier of 1011) . 



<Add> 

<CmdID>4</CmdID> 
<Item> 

<Target> 

<LocURI> . /1011/</LocURI> 
</Target> 
<Source> 

<LocURI> . /1/7/</LocURI> 
<LocName>New Folder</LocName> 
</Source> 
</ltem> 

</Add> 

The client should return mapping information to the 
server indicating for the server how to relate the identifier 
of the server folder to that of the client folder, and the 
server should identify the folders using the client's folder 
identifiers. Thus, the Target element within the Item of an 
operational element sent by the server should always contain 
the client side folder path. 

In case a new folder has been created on the server, and 
a message has been added to the folder, the server must send 
its folder operations (i.e. the Add command containing the 
folder information) in the first message of the server 
modifications package, and the Final flag must not be 
specified in the message. The client must be able to return 
folder identifier mapping information to the server in the 
subsequent message, so that the server can specify the 
client's folder identifier within the Target of the Add 
operation containing the actual message. 

Renaming Folders 

Since the display name of a folder is transferred within 
a LocName element, there is no special operation for renaming 
folders. Therefore, when the displayable name of a folder has 
been changed, a Replace command should be sent, and the 
LocName element should contain the new displayable name of the 
folder . 
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Moving Folders 

Since the entire path of a folder is transferred within a 
LocURI element, there is no special operation for moving 
folders. Therefore, when a folder has been moved into another 
folder, a Replace command should be sent, and the new folder 
path should be included in the LocURI element. If a new 
folder has been created in the server, and an existing folder 
has been moved into the new folder, the server should first 
add the new folder to the client, and after receiving the 
mapping information for the folder identifier, the server 
should move the existing folder, i.e. it should then send the 
Replace command containing the new client side folder path. 

Cooperation between Application Elements , Sync Elements , and 
the Sync Engine 

One possible scheme by which the client and server 
applications 11a lib and sync elements lib 12b and server sync 
engine 12 cooperate to handle changes in data organization 
(directory structure) is indicated in Fig. 1 and also in Fig. 
3, but such schemes are not the subject of the invention. 
What is important to understand is that the invention provides 
that the client and server sync elements lib 12b need not 
parse a SyncML message down to the level of a data element in 
order to extract information having to do with changes in data 
organization, and that the client and server applications 11a 
12a need not understand anything about the directory structure 
in order to access their respective data stores lie 12c to be 
able to add, replace, or delete data. 

Nevertheless, referring again to Fig. 1 and Fig. 3, in 
one arrangement for synchronizing the two data stores 11c 12c, 
in a first step 31a, the server sync agent 12b establishes a 
transport connection with the client sync agent lib (the 
reciprocal action taken by the client sync agent being 
implied, but not shown in Fig. 3) . In a next step 31b, the 



client application 11a (assuming only one application, 
although there can be more than one, all sharing the same data 
store) determines changes in the client data store 11c since 
the last synchronization and the client sync agent does the 
same for the folders in the data store 11c. Next, in a step 
31c, the sync agent places folder changes in commands 
(protocol command elements) using data identification elements 
to reference affected folders, with the data identification 
elements external to any data elements, as explained above. 
Next, in a step 31d, the application places data unit changes 
in commands using a data description element (a data, item or 
met a element) . Next, in a step 31e, the sync agent sends to 
the server 12 a message bearing commands with data description 
elements and data identification elements (external to any 
data elements) . 

Next, at the server 12, in a next step 31f, the sync 
agent 12b extracts the folder changes from any commands with 
client data identification elements external to any data 
elements, and based on what commands contained the client data 
identification elements, indicates to the sync engine 12f what 
changes were made to the client data store data structure 
since the last synchronization. In a next step 31g, the sync 
engine resolves folder conflicts and provide net folder 
changes to the server sync agent 12b; the server sync agent 
12b makes corresponding folder changes to the server data 
store 12c; and the server sync agent then gives the (server) 
sync engine the rest of the message (conveying any data unit 
changes by client) . In a next step 31h, the sync engine 12f 
resolves any data unit conflicts with the server data store 
that would be caused if the changes made to the client data 
store 11c were all made also to the server data store 12c, and 
provides the net data unit changes to the server application 
12a. In a next step 31i, the server application makes the 
indicated data unit changes to the server data store 12c, and 



places the net data unit changes to the client data store 11c 
in appropriate commands. Then, in a next step 31 j , the server 
sync agent collects the net changes to be made to the folders 
in the client data store 11c and adds corresponding commands 
5 including data identification elements indicating the affected 

folders, the data identification elements being placed 
external to any data elements within the message. (The 
message is then sent to the client.) 

When the client 11 receives the server message, in a next 
10 step 31k, the client sync agent lib extracts all folder 

changes by parsing the commands down to but not including any 
data elements included in the commands, changes the client 
data store 11c accordingly, and provides to the application 
11a all commands for data unit changes. Finally, in a step 
15 31m, the application 11a changes the client data store 11c 

according to the commands provided by the client sync agent 
lib. 

Conclusion 

It is to be understood that the above-described 
20 arrangements are only illustrative of the application of the 

principles of the present invention. Numerous modifications 
and alternative arrangements may be devised by those skilled 
in the art without departing from the scope of the present 
invention, and the appended claims are intended to cover such 
25 modifications and arrangements. 
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